Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/main/java/com/codeit/team5/mopl/config/BatchConfig.java`:
- Around line 94-96: `TmdbMovieItemReader` is being created as a singleton
`@Bean`, but it keeps mutable step state like `currentPage`, `endPage`,
`totalPages`, and `buffer` initialized via `@BeforeStep`, so concurrent
`asyncJobLauncher` runs can share and overwrite state. Update the reader bean in
`BatchConfig.tmdbMovieItemReader()` to use `@StepScope` so each step gets its
own instance; apply the same scoped pattern to the other stateful readers
(`TmdbTvSeriesItemReader`, `SportsDbEventItemReader`, `SportsDbDayItemReader`)
to prevent cross-run interference.
- Around line 58-64: The async job launcher in BatchConfig should not use
SimpleAsyncTaskExecutor because it can create unbounded threads; switch
asyncJobLauncher to a bounded ThreadPoolTaskExecutor with a configured
concurrency limit and keep the TaskExecutorJobLauncher wiring intact. Also, the
batch readers under content/batch/reader that rely on `@BeforeStep-populated`
mutable fields (such as buffer/currentPage/endPage) should be made step-scoped
by adding `@StepScope` so each step execution gets its own reader instance instead
of sharing singleton state.

In
`@src/main/java/com/codeit/team5/mopl/content/batch/processor/SportsDbEventItemProcessor.java`:
- Around line 29-32: The duplicate check in SportsDbEventItemProcessor is
outside the write boundary, so concurrent runs can still pass the same idEvent
into the writer and create duplicate rows or unique-constraint failures. Fix
this by making the final persistence path in the writer/upsert layer
authoritative: add a database-level unique constraint on (source, external_id)
and handle conflicts with upsert/ignore semantics, or at minimum re-check
against the batch before writing using the existing SportsDbEventItemProcessor
and writer flow. Keep the existing existsBySourceAndExternalId() filter only as
an optimization, not as the source of truth.

In
`@src/main/java/com/codeit/team5/mopl/content/batch/processor/TmdbMovieItemProcessor.java`:
- Around line 20-71: TmdbMovieItemProcessor duplicates the same thumbnail, tag,
and metadata-building logic already present in TmdbTvSeriesItemProcessor, so
extract the shared behavior into a common helper or base abstraction. Move
resolveTagNames, buildMetadata, and thumbnailUrl construction into a reusable
utility or generic processor helper that accepts DTO field accessors (id, title,
genreIds, voteAverage, originalLanguage), then have both TMDB processors
delegate to it to keep movie and TV series handling consistent.

In
`@src/main/java/com/codeit/team5/mopl/content/batch/reader/SportsDbDayItemReader.java`:
- Around line 24-43: 리그 조회 중 하나의 예외가 전체 `beforeStep`을 실패시키며 이미 수집한 `buffer`
데이터까지 잃는 문제가 있습니다. `SportsDbDayItemReader.beforeStep`에서
`sportsDbApiClient.fetchEventsByDay(...)` 호출을 리그 단위로 예외 처리해, 실패한
`SportsDbLeague`만 로그로 남기고 다음 리그를 계속 처리하도록 변경하세요. 성공적으로 받은
`SportsDbEventListResponse`와 `buffer.addAll(events)`는 그대로 유지하되, 예외가 발생한 경우에는 해당
리그 이름과 날짜를 포함해 경고를 남기고 루프를 중단하지 않게 하세요.

In
`@src/main/java/com/codeit/team5/mopl/content/batch/reader/SportsDbEventItemReader.java`:
- Around line 21-45: `SportsDbEventItemReader` and `SportsDbDayItemReader` are
holding mutable `buffer` state inside singleton readers, so they must be made
step-scoped instead of shared beans. Update the Reader bean definitions in
`BatchConfig` to use `@StepScope` so each Step gets a fresh instance, and keep
the `beforeStep`/`read()` flow in each reader unchanged except for removing any
reliance on shared state; do not try to fix this with only `buffer.clear()`.

In
`@src/main/java/com/codeit/team5/mopl/content/batch/reader/TmdbMovieItemReader.java`:
- Around line 54-65: In TmdbMovieItemReader.fetchNextPage(), add an early-exit
path when response.results() is empty so the reader stops instead of continuing
through currentPage until totalPages; update the read loop state in
TmdbMovieItemReader (and any end-of-data flag used there) to mark completion
immediately on a blank TMDB page. Keep the existing buffering logic for
non-empty pages, but make sure the empty-page check happens right after fetching
the TmdbMovieListResponse and before incrementing currentPage or sleeping.

In
`@src/main/java/com/codeit/team5/mopl/content/batch/reader/TmdbTvSeriesItemReader.java`:
- Around line 54-65: The TV series reader currently keeps advancing even when
tmdbApiClient.fetchTvSeries returns an empty page, because fetchNextPage only
fills buffer and increments currentPage. Update TmdbTvSeriesItemReader so
fetchNextPage (or read) detects an empty response.results() and sets the same
early-termination state used by the movie reader, then stop further page
fetching immediately. Make the change in the TmdbTvSeriesItemReader
read/fetchNextPage flow so empty TMDB pages end the batch instead of continuing
to call the API.

In
`@src/main/java/com/codeit/team5/mopl/content/batch/scheduler/ContentCollectionScheduler.java`:
- Around line 42-68: 스케줄 실행 기준 타임존이 명시되지 않아 `@Scheduled` 크론과 `LocalDate.now()`가
JVM 기본 타임존에 의존하는 문제가 있습니다. `ContentCollectionScheduler`의 `runTmdbMovieJob`,
`runTmdbTvSeriesJob`, `runSportsDbDayJob`에서 동일한 `ZoneId`를 사용하도록 `@Scheduled(zone
= "...")`를 지정하고, `LocalDate.now(...)`도 같은 기준으로 맞추세요. 공통 타임존은 상수나 프로퍼티로 분리해 크론과
날짜 파라미터가 항상 같은 기준을 공유하게 하세요.

In
`@src/main/java/com/codeit/team5/mopl/content/batch/writer/ContentItemWriter.java`:
- Around line 62-70: `ContentItemWriter`의 썸네일 저장 로직은 `externalId`만 중복 제거한 뒤
`thumbnailUrl`이 같은 항목들을 그대로 `saveAll`하고 있어,
`Collectors.toMap(BinaryContent::getUrl, ...)`에서 동일 URL이 나오면 청크가 실패합니다.
`deduplicatedItems`에서 `thumbnailUrl` 기준으로 한 번 더 중복 제거한 뒤
`binaryContentRepository.saveAll(...)`에 넘기고, `toMap`에는 `BinaryContent::getUrl`
충돌 시 기존 값을 유지하거나 새 값을 선택하는 merge 함수를 추가해 `IllegalStateException`이 나지 않도록 수정하세요.

In
`@src/main/java/com/codeit/team5/mopl/content/controller/ContentCollectionController.java`:
- Around line 102-108: ContentCollectionController.run(...) is swallowing
asyncJobLauncher.run(...) failures, so callers still get a success response even
when the job never starts. Update run(Job, JobParameters) to propagate the
caught JobExecutionAlreadyRunningException, JobRestartException,
JobInstanceAlreadyCompleteException, and JobParametersInvalidException by
rethrowing them or converting them to a ResponseStatusException so the endpoint
failure is visible. Keep the existing logging in
ContentCollectionController.run, but make sure the failure reaches the
controller response path instead of being ignored.
- Around line 89-92: The collectSportsEventsByDay endpoint currently validates
date only with a regex, so invalid calendar dates can still pass through. Update
the ContentCollectionController.collectSportsEventsByDay request parameter to
use LocalDate with `@DateTimeFormat`(iso = ISO.DATE) so both format and real date
validity are enforced, or add a custom validator if the String signature must
remain. Make sure the change is applied on the date parameter in the
collectSportsEventsByDay method while preserving the existing 202 response
behavior for valid inputs.

In
`@src/main/java/com/codeit/team5/mopl/content/dto/request/ValidPageRangeValidator.java`:
- Around line 9-12: The ValidPageRangeValidator class is re-checking null and
minimum-value constraints that are already handled by field validation, causing
duplicate errors. Update isValid(PageRangeRequest, ConstraintValidatorContext)
to only enforce the cross-field rule that endPage must not be less than
startPage, and attach the violation to the endPage field through the
ConstraintValidatorContext instead of returning a generic class-level error.

In
`@src/test/java/com/codeit/team5/mopl/content/batch/reader/TmdbMovieItemReaderTest.java`:
- Around line 78-88: The test in
TmdbMovieItemReaderTest::beforeStep_endPageExceedsMax_clampsTo500 does not
actually verify the clamping behavior because the stubbed
TmdbApiClient.fetchMovies(1) returns totalPages=1, making Math.min(totalPages,
endPage) always resolve to 1. Update the test setup so the initial
TmdbMovieListResponse reports totalPages greater than MAX_PAGE (for example,
1000), then exercise reader.beforeStep(createStepExecution("1", "9999")) and
assert that pages beyond 500 are never requested or that read() returns null
once the 500-page limit is reached. Use the reader, beforeStep, read, and
fetchMovies interactions to confirm the clamp is enforced.

In
`@src/test/java/com/codeit/team5/mopl/content/batch/writer/ContentItemWriterTest.java`:
- Around line 46-116: `ContentItemWriterTest` is missing coverage for the tag
flow handled by `ContentItemWriter`. Add tests around `write(...)` using
`ContentWithMetaData` with `tagNames` to verify `tagRepository` is queried,
existing tags are reused when found, new tags are created when absent, and
`ContentTag` links are persisted. Use the existing `contentRepository`,
`tagRepository`, and `contentStatsRepository` mocks to stub and verify the
tag-related behavior alongside the current save/thumbnail assertions.

---

Outside diff comments:
In
`@src/test/java/com/codeit/team5/mopl/content/controller/ContentCollectionControllerTest.java`:
- Around line 89-112: TMDB TV 시리즈 수집 테스트에 startPage 하한 검증 케이스가 빠져 있습니다.
ContentCollectionControllerTest의 collectTmdbTvSeries_* 테스트들에, startPage가 0 이하일 때
/api/admin/contents/collect/tmdb/tv가 400을 반환하는 케이스를 추가해 Movie 수집 테스트와 동일한
PageRangeRequest/@ValidPageRange 커버리지를 맞추세요. 필요하면
collectTmdbTvSeries_missingParams_returnsBadRequest와
collectTmdbTvSeries_endPageLessThanStartPage_returnsBadRequest 패턴을 따라 같은 MockMvc
호출 방식으로 보완하면 됩니다.

---

Duplicate comments:
In
`@src/main/java/com/codeit/team5/mopl/content/batch/processor/TmdbTvSeriesItemProcessor.java`:
- Around line 20-71: `TmdbTvSeriesItemProcessor` duplicates the same TMDB
processing flow already present in `TmdbMovieItemProcessor`, so apply the same
refactor here by extracting the shared logic into a common base/helper and reuse
it from `process`, `resolveTagNames`, and `buildMetadata`. Keep only
TV-series-specific parts in this class, such as `ContentType.TV_SERIES`,
`dto.firstAirDate()`, and the TV-specific tag/metadata inputs.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/main/java/com/codeit/team5/mopl/config/BatchConfig.java`:
- Around line 90-96: `BatchConfig`의 각 Step 설정에서
`noSkip(WebClientException.class)`가 `SelectiveRetryPolicy`의 상태코드별 판단을 덮어쓰고 있어,
4xx/404 같은 항목 단위 오류까지 전체 Step 실패로 이어질 수 있습니다. `faultTolerant()` 체인에서
`skip()/noSkip()` 구성을 `SelectiveRetryPolicy`와 일치하도록 좁히거나 `TmdbSkipPolicy` 같은 커스텀
`SkipPolicy`로 대체해 `WebClientResponseException`을 상태코드 기준으로 처리하세요. 또한 스킵된 항목을 추적할
수 있도록 각 Step에 `SkipListener`를 등록해 어떤 아이템이 왜 스킵됐는지 로깅하도록 추가하세요.
- Around line 84-97: Move the TMDB external fetches out of the reader read()
path for TmdbMovieItemReader and TmdbTvSeriesItemReader, since HTTP calls and
Thread.sleep() should not run inside the chunk transaction. Follow the pattern
used by SportsDbEventItemReader and SportsDbDayItemReader: preload data in
`@BeforeStep` (or a separate prefetch step) and make read() only return buffered
items via buffer.poll(). Keep BatchConfig’s tmdbMovieStep wiring the same, but
ensure these reader classes no longer do network I/O or waiting during read().

In
`@src/main/java/com/codeit/team5/mopl/content/batch/exception/BatchJobLaunchException.java`:
- Around line 6-11: `BatchJobLaunchException` currently only accepts `jobName`,
so the original failure cause cannot be preserved; update the exception
hierarchy to support cause chaining consistently. Add a `Throwable`-aware
constructor or equivalent support in `BusinessException`, then have
`BatchJobLaunchException` pass the underlying cause through instead of dropping
it. Align this with the existing `initCause(cause)` pattern used by other
exceptions in the same hierarchy so callers can trace the root error from
`BatchJobLaunchException` and `BusinessException`.

In
`@src/main/java/com/codeit/team5/mopl/content/batch/retry/SelectiveRetryPolicy.java`:
- Line 21: Replace the hardcoded 429 magic number in SelectiveRetryPolicy with
the standard Spring HttpStatus.TOO_MANY_REQUESTS value, and update any related
retry checks that reference the TOO_MANY_REQUESTS constant. Use the HttpStatus
enum directly in the policy logic so the intent is explicit and the code is less
error-prone; keep the change localized to the retry status comparison and any
helper methods in SelectiveRetryPolicy that depend on that constant.

In
`@src/main/java/com/codeit/team5/mopl/content/batch/scheduler/ContentCollectionScheduler.java`:
- Around line 72-79: The `run(Job job, JobParameters params)` catch block in
`ContentCollectionScheduler` is only logging `e.getMessage()`, so update the
`log.error` call to include the full exception object and stack trace, matching
the behavior used in `ContentCollectionController.run()`. Keep the same error
context with `job.getName()`, but pass the caught exception itself as the final
argument so scheduler failures are easier to diagnose.

In
`@src/test/java/com/codeit/team5/mopl/content/controller/ContentCollectionControllerTest.java`:
- Around line 140-148: Add a test in ContentCollectionControllerTest for the
invalid league enum path so the new MethodArgumentTypeMismatchException handling
is covered. In collectSportsEvents_success’s соседний SportsDB request flow,
create a case that calls the same /api/admin/contents/collect/sports endpoint
with an invalid league value and asserts a 400 Bad Request, verifying the
SportsDbLeague parameter parsing failure is wired to the global exception
handler.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@src/main/java/com/codeit/team5/mopl/content/batch/processor/TmdbMovieItemProcessor.java`:
- Around line 52-58: `TmdbMovieItemProcessor.resolveTagNames` currently assumes
`dto.genreIds()` is always non-null, which can NPE when TMDB omits `genre_ids`.
Add a null-safe default at the DTO level by giving `genreIds` a default empty
list in `TmdbMovieDto`, and apply the same safeguard to the similarly shaped
`TmdbTvDto` to prevent the issue from recurring. Keep `resolveTagNames` focused
on mapping IDs to labels, relying on the DTOs to always return a non-null list.

In
`@src/main/java/com/codeit/team5/mopl/content/batch/processor/TmdbTvSeriesItemProcessor.java`:
- Around line 52-58: `TmdbTvSeriesItemProcessor.resolveTagNames` assumes
`dto.genreIds()` is non-null, so add null handling before streaming to avoid NPE
and skipped batch items. Normalize a null genre list to an empty list inside
`resolveTagNames()` or set a default `List.of()` on `TmdbTvDto`, and make the
same null-safe adjustment in the analogous movie processor so both processors
follow the same pattern.

In
`@src/main/java/com/codeit/team5/mopl/content/batch/reader/SportsDbEventItemReader.java`:
- Around line 19-40: `SportsDbEventItemReader.beforeStep`에서
`sportsDbApiClient.fetchEventsBySeason` 호출이 재시도 없이 바로 실행되는 문제가 있습니다.
`SportsDbDayItemReader`, `TmdbMovieItemReader`, `TmdbTvSeriesItemReader`와 동일하게
`RetryTemplate`을 생성자에 주입하고, `beforeStep` 내부의 `fetchEventsBySeason`를
`retryTemplate.execute(...)`로 감싸서 일시적 오류 시 재시도되도록 수정하세요. 또한
`BatchConfig.sportsDbEventItemReader()` 빈 생성자 호출에도 `retryTemplate` 인자를 추가해 연결되게
하세요.

In
`@src/main/java/com/codeit/team5/mopl/content/batch/reader/TmdbTvSeriesItemReader.java`:
- Around line 19-75: `TmdbTvSeriesItemReader` duplicates nearly the same paging
and buffering flow as `TmdbMovieItemReader`, so extract the shared logic into a
common abstract reader to avoid drift. Create a generic base such as
`AbstractTmdbPagedItemReader<T>` that owns the `beforeStep` loop,
`RetryTemplate` call, buffer management, and logging, then let
`TmdbTvSeriesItemReader` and `TmdbMovieItemReader` provide only the page fetch
method and item validity check (for example, name/title non-blank). Keep the
existing reader class names and `read()` behavior, but move the shared
page-processing code into the base class.

In
`@src/main/java/com/codeit/team5/mopl/content/batch/scheduler/ContentCollectionScheduler.java`:
- Around line 72-79: run(Job job, JobParameters params) in
ContentCollectionScheduler only catches four Spring Batch exceptions, so
unexpected failures from asyncJobLauncher.run() can bypass the
scheduler-specific error log. Broaden the catch in run() to include general
Exception (while keeping the existing batch-specific exceptions) and log the job
name plus the throwable with the same "[Scheduler] Job 실행 실패" context so any
runtime failure is captured consistently.

In
`@src/main/java/com/codeit/team5/mopl/content/controller/ContentCollectionController.java`:
- Around line 77-90: The season parameter validation in
ContentCollectionController.collectSportsEvents currently only checks the
YYYY-YYYY format, so unsupported seasons can still reach the job; replace or
augment the `@Pattern` validation with a custom validator that checks the
requested season against SportsDbLeague.getSeasons() for the selected league.
Update the request handling so invalid seasons are rejected at the controller
boundary with a 400 before run(...) is called, and keep the validation logic
tied to SportsDbLeague so season list changes only need one update point.

In
`@src/main/java/com/codeit/team5/mopl/content/dto/external/sportsdb/SportsDbLeague.java`:
- Around line 19-20: `SportsDbLeague`의 `SEASONS`가 하드코딩된 문자열 목록이라 매년 수동 갱신이 필요하니,
현재 연도를 기준으로 최신 시즌을 동적으로 생성하는 헬퍼로 바꾸고 `getSeasons()`가 실제로 사용되는지 함께 확인하세요.
`SEASONS` 선언과 `getSeasons()` 주변을 수정해 SportsDB 지원 범위에 맞는 시즌 목록을 계산하도록 정리하고, 소비처가
없다면 제거하거나 향후 `/sports` 시즌 검증용으로 연결될 의도를 명확히 해주세요.

In
`@src/test/java/com/codeit/team5/mopl/content/batch/processor/TmdbMovieItemProcessorTest.java`:
- Around line 83-97: The test in TmdbMovieItemProcessorTest is too weak because
it only checks that tagNames is non-empty, not that the mapped genre label is
correct. Update process_validGenreId_tagNamesIncluded to assert the exact
expected tag value returned by TmdbMovieItemProcessor.resolveTagNames(), using
TmdbMovieGenre.fromId(18L).getLabel() with containsExactly so the test verifies
the specific mapping and stays consistent with SportsDbEventItemProcessorTest.

In
`@src/test/java/com/codeit/team5/mopl/content/batch/writer/ContentItemWriterTest.java`:
- Line 127: The test uses a fully qualified Mockito call for never() even though
the file already imports never statically, creating inconsistent style in
ContentItemWriterTest. Update the verify(...) call in the
binaryContentRepository assertion to use the same imported never() form used
elsewhere in the file, keeping the notation consistent with the other Mockito
verifications.

---

Outside diff comments:
In
`@src/test/java/com/codeit/team5/mopl/user/controller/UserControllerIntegrationTest.java`:
- Around line 223-232: `getUser_invalidUuid` in `UserControllerIntegrationTest`
only checks the HTTP status, so strengthen it to match the other bad-request
tests in this class by asserting the error response body as well. Update the
`mockMvc.perform(...)` expectations to verify the same error payload fields used
elsewhere (for example `$.exceptionType` and `$.message`) so the
`UserController`/global exception handling for invalid UUIDs is validated end to
end.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@src/main/java/com/codeit/team5/mopl/content/batch/scheduler/ContentCollectionScheduler.java`:
- Around line 68-74: `ContentCollectionScheduler.run(Job, JobParameters)` is
duplicating the same `asyncJobLauncher.run(...)` plus failure-handling pattern
used in `ContentCollectionController.run(Job, JobParameters)`. Extract the
shared batch execution flow into a common helper/component such as
`BatchJobRunner`, and let both callers delegate to it while preserving their
different failure behavior via a flag or callback (scheduler logs-and-swallow,
controller wraps in `BatchJobLaunchException`). Keep the logging/error handling
centralized so future changes to `asyncJobLauncher` invocation or error
formatting only need to be made once.

---

Duplicate comments:
In
`@src/main/java/com/codeit/team5/mopl/content/controller/ContentCollectionController.java`:
- Around line 73-86: 컨트롤러의 collectSportsEvents는 season 형식만 검증하고 실제로
SportsDbLeague가 지원하는 시즌인지 확인하지 않으므로, 요청 진입 시점에 지원 시즌 검증을 추가해야 합니다.
SportsDbLeague의 getSeasons()를 사용해 season이 목록에 포함되는지 검사하거나, `@ValidSeason` 같은 커스텀
검증기로 묶어 collectSportsEvents에서 실행 전에 400으로 막도록 수정하세요. 검증 대상은 league와 season 조합이며,
sportsDbEventJob 실행 전에 실패 처리되도록 연결하면 됩니다.